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ABSTRACT 

Modem space transportation and ground support system designs are becoming increasingly 
sophisticated and complex. Determining the health state of these systems using traditional parameter 
limit checking, or model-based or rule-based methods is becoming more difficult as the number of 
sensors and component interactions grows. Data-driven monitoring techniques have been developed to 
address these issues by analyzing system operations data to automatically characterize normal system 
behavior. System health can be monitored by comparing real-time operating data with these nominal 
characterizations, providing detection of anomalous data signatures indicative of system faults, 
failures, or precursors of significant failures. The Inductive Monitoring System (IMS) is a general 
purpose, data-driven system health monitoring software tool that has been successfully applied to 
several aerospace applications and is under evaluation for anomaly detection in vehicle and ground 
equipment for next generation launch systems. After an introduction to IMS application development, 
we discuss these NASA online monitoring applications, including the integration of IMS with 
complementary model-based and rule-based methods. Although the examples presented in this paper 
are from space operations applications, IMS is a general-purpose health-monitoring tool that is also 
applicable to power generation and transmission system monitoring. 


INTRODUCTION 

Space transportation systems and launch site ground support systems are very complex, with a large 
number of sensors and many interactions between components. Monitoring the health of these systems 
under various operating conditions and detecting subtle system degradation is difficult. Various 
methods have been employed to assist operators with the monitoring task, including parameter limit 
checking, model-based systems, and rule-based systems. Parameter limit checking is in widespread use 
because of its simplicity. However, it requires significant operator training to interpret and respond 
appropriately to potentially large combinations of simultaneous alerts. Model-based and rule-based 
systems move much of the cognitive load from the operator to the computer by encoding the operation 
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of the system and automating some of the deductive reasoning an operator must perform. However, 
both model-based and rule-based systems require the manual extraction of system knowledge. 
Developing a model of a system requires significant effort to fully understand and accurately encode 
its internal operation. Developing a complete set of rules to correctly define nominal relationships 
among sensors under diverse operating conditions similarly requires significant effort. Data-driven 
monitoring techniques have been developed to address these issues. 

Data-driven techniques are complementary to, but also have a number of advantages over, other 
methods for monitoring complex space vehicles and launch systems. Unlike model-based systems, the 
developer does not need to understand or encode the internal operation of the system. The knowledge 
required to monitor the system is automatically derived from archived system operations data. Unlike 
rule-based systems, data-driven systems do not require system analysts to manually define nominal 
relationships among sensors; the data-driven system automatically extracts relationships. Data-driven 
techniques are not limited to low-dimensional spaces and work as effectively with dozens of 
parameters as they do with a few. Furthermore, knowledge bases formed by data-driven techniques are 
easy to update. As the operating envelope of the monitored system is expanded, data-driven techniques 
can be quickly retrained to incorporate the new behavior into the knowledge base. The expertise and 
the time-consuming process of updating a model or rule base to maintain consistency with the new 
operation are not required. 

There are numerous examples of data-driven systems, including systems that use support vector 
machines (SVM, reference 1, e.g., NASA Ames Research Center (ARC)’s Mariana), nearest neighbors 
(reference 2, e.g., Orca, cooperatively developed by ISLE and NASA), neural networks (reference 3, 
numerous, including Gensym’s Neuronline), clustering (e.g., NASA ARC’s IMS), hybrid (reference 4, 
e.g., NASA Jet Propulsion Laboratory’s BEAM), as well as conventional numerical statistics. We will 
focus on one of these - IMS - in particular. 


INDUCTIVE MONITORING SYSTEM (IMS) 

The Inductive Monitoring System (IMS, references 5 - 7) is a general purpose, data-driven system 
health monitoring software tool that has been successfully applied to several aerospace applications 
and is under evaluation for anomaly detection of vehicle and ground equipment for next generation 
launch systems. 

One powerful feature of many data driven anomaly detection techniques is the ability to 
simultaneously analyze multiple parameters. This feature allows them to discover and model 
interactions between related parameters that might be difficult to notice when monitoring the 
parameters individually. A basic data structure used for distance-based analysis is a vector of 
parameter values (Figure 1). Vectors containing N values are treated as points in an A-dimensional 
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Figure 1: Sample data vector. 
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vector space. An appropriate distance metric is used to calculate the distance between these points. The 
familiar Euclidean distance metric has proven effective in many applications, though other metrics 
may also be useful. The underlying premise of distance-based anomaly detection is that anomalous 
data points will fall a significant distance away from typical, nominal data points. 

For system health monitoring applications, vector parameters are typically instantiated with concurrent 
sensor values collected from a time slice of the data stream. Additional computed (derived) values or 
parameter values from previous data samples could also be included in the vector. For instance, 
increased system insight can often be obtained by incorporating values in the vector such as the rate of 
change of a pressure, the difference between two related temperature sensors, or the difference 
between commanded and actual values for a set point or actuator position. Also, augmenting the vector 
with values collected during previous time slices can implicitly capture short-term system operation 
patterns and trends. Flight controllers and engineers familiar with the monitored system can often 
suggest useful telemetry and derived parameters to use in the health monitoring vectors. Before 
processing, these vector values are typically normalized by applying z-score normalization or a similar 
method to each of the parameters. 

IMS uses a data-driven technique called clustering to extract models of normal system operation from 
archived data. IMS works with vectors of data values, as described above. During the learning process, 
IMS analyzes data collected during periods of normal system operation to build a system model. It 
characterizes how the parameters relate to one another during normal operation by finding areas in the 
vector space where nominal data tends to fall. These areas are called nominal operating regions and 
correspond to clusters of nearby, similar points found by the IMS clustering algorithm. IMS represents 
these nominal operating regions as hyper-boxes in the vector space, providing a minimum and 
maximum value limit for each parameter of a vector contained in a particular hyper-box (Figure 2). 
These hyper-box cluster specifications are stored in a knowledge base that IMS uses for real-time 
telemetry monitoring or archived data (post-flight) analysis. 
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Figure 2: Sample IMS cluster hyper-box. 


During the monitoring operation, IMS reads and normalizes real-time or archived data values, formats 
them into the predefined vector structure, and searches the knowledge base of nominal operating 
regions to see how well the new data vector fits the nominal system characterization. After each 
search, IMS returns the distance from the new vector to the nearest nominal operating region, called 
the composite distance. Data that matches the nominal training data well will have a composite 
distance of zero. If one or more of the data parameters is slightly outside of expected values, a small 
non-zero result is returned. As incoming data deviates further from the normal system data, indicating 
a possible malfunction, IMS will return a higher composite distance value to alert users to the anomaly. 
IMS also calculates the contribution of each individual parameter to the composite deviation, which 
can help identify and isolate the cause of the anomaly. 
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IMS SPACE APPLICATIONS 


IMS has been deployed in NASA mission control to support real-time telemetry monitoring and has 
generated interest in data-driven monitoring capability for other NASA programs. Several projects 
were undertaken to mature the IMS technology and complementary tools for use in NASA’s 
Constellation program, including pre-launch ground diagnostics for NASA’s Ares I-X development 
flight test and Ares I ground support equipment health monitoring. 

INTERNATIONAL SPACE STATION 

NASA’s International Space Station (ISS) flight control team is responsible for fault management 
activities. To assist with this task, IMS has been deployed in support of two flight control disciplines: 
attitude control and thermal operations. The Attitude Determination and Control Officer (ADCO) 
monitors, among other systems, the Control Moment Gyroscope (CMG) and Rate Gyro Assembly 
(RGA) systems. The Thermal Operations (THOR) officer monitors the External Thermal Control 
System (ETCS) as well as other related systems. 

The ISS Control Moment Gyroscope (CMG) attitude 
control system consists of four large gyroscopes, each 
mounted in a gimbal system that can rotate the CMG 
about the two axes perpendicular to the gyroscope spin 
axis (Figure 3). The CMGs operate as non-propulsive 
attitude control devices that exchange momentum with 
the ISS through induced gyroscopic torques. 

As they have aged, some of the CMGs have degraded 
enough to malfunction and require replacement. Given 
their history, the ADCO flight controllers are interested 
in detecting early symptoms of degradation in the 
CMGs. 



Working with ADCO flight controllers, nine 
, . . - , . , n ,,o , Figure 3: ISS Control Moment Gyroscopes, 

telemetered and four derived CMG parameters were 

selected for real-time monitoring. Seven to ten months 

of archived data was analyzed for each of the four CMGs. The data was sampled at a 1 Hz rate, formed 
into vectors of 13 values, and four IMS monitoring knowledge bases were constructed from the 
collected data. Each CMG was analyzed individually to capture its unique characteristics. 


The IMS monitoring application was integrated with the NASA Mission Control data server software 
to access real-time telemetry in the ISS flight control room. Four IMS processes, one per CMG, run on 
the ADCO flight control console to provide continuous real-time monitoring. Once per second, each 
process compares incoming telemetry data with the appropriate CMG knowledge base and returns the 
amount of overall deviation, if any, from the nominal training data. It also returns the contribution of 
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each individual parameter to any deviation to aid in isolating the source of the deviation. These IMS 
results are published back to the Mission Control data server for access and monitoring by other 
Mission Control software applications. IMS composite distances are plotted on ADCO console 
displays and automated alerts issued if significant deviations occur. 
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Figure 4: ISS Control Moment Gyro (CMG) failure. IMS detected failure symptoms 15 hours prior. 


Figure 4 shows an example from the 
monitoring of one of the CMGs. IMS 
detected precursor failure symptoms, as 
evidenced by the sudden jump in 
“Distance from Nominal” values, more 
than 15 hours before the eventual failure 
and spin down of the gyroscope occurred. 

Successful deployment and certification of 
the IMS CMG monitoring system led to 
further development of real-time data- 
driven monitoring for ISS subsystems. The 
IMS CMG application was generalized to 
accept an arbitrary number of user- 
selected input parameters and to run on 
any controller console in the ISS flight 
control room. The resulting tool, called 
AMISS for Anomaly Monitoring Inductive 
Software System, has been applied to the 



Figure 5: ISS external view showing ETCS radiators at 
lower left and lower right. 
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thermal operations (THOR) domain, monitoring subsystems of the ISS External Thermal Control 
System (ETCS). 

The ETCS is used to dissipate heat onboard ISS. Excess thermal energy from inside the ISS is 
transferred to liquid ammonia cooling loops in the ETCS. The heated ammonia is then circulated to 
radiators and cooled as thermal energy is released into space (Figure 5). ETCS systems are separated 
into two independent loops with three major subsystems each: the Pump Module (PM), the Ammonia 
and Nitrogen Tank Assemblies (ATA/NTA), and the Radiators (RAD). The PM circulates coolant 
through the ETCS, the ATA/NTA stores reserve ammonia coolant and maintains pressure within the 
ETCS systems, and the RAD system controls the flow of coolant to each of three thermal radiators. 

AMISS knowledge bases were constructed from a year of archived ETCS operational data, one 
knowledge base for each major ETCS subsystem, and two knowledge bases covering all pertinent 
parameters in each ETCS loop. The subsystem modules monitor for anomalies that occur within each 
subsystem while the full loop modules also watch for anomalies that are only apparent in subsystem 
interactions. 

Figure 6 shows an example of an anomaly detected by IMS/AMISS in an early configuration of the 
ETCS. In early January 2007, the ISS EETCS (Early External Thermal Control System) developed an 
ammonia gas bubble in the normally liquid ammonia lines. Off-line IMS analysis after the event was 
able to detect the bubble as it began to grow, approximately six days prior to the bubble being 
detectable by standard telemetry monitoring methods. Using traditional monitoring, the controllers 
detected the anomaly nine hours before the bubble “burst” and dissipated back into liquid. 
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Figure 6: ISS External Thermal Control System anomaly. IMS detected the anomaly six days prior. 


CONSTELLATION PROGRAM 

NASA’s Constellation Program, part of President Bush’s 2004 Vision for Space Exploration, aims to 
return man to the Moon and then venture to Mars and beyond. To accomplish that goal, NASA is 
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developing three new vehicles - the Ares I crew launch vehicle, the Ares V cargo launch vehicle, and 
the Orion crew exploration vehicle. To support these vehicles, NASA is also updating the ground 
support equipment (GSE) necessary to support such operations as transporting, receiving, handling, 
assembly, inspection, test, checkout, servicing, launch, and recovery of space systems. As of this 
writing, the Constellation program is in jeopardy and may be cancelled. However, the concepts 
presented here are expected to be applicable to the space vehicles and the necessary upgrades of 
NASA’s launch complex for future programs. 

IMS has been demonstrated for anomaly detection for both Ares I-X (the test flight of Ares I, as 
described below) and ground support equipment. 


ARES I-X 

Ares I-X was the first uninhabited test flight of Ares I (reference 8). It 
launched on October 28, 2009 (see Figure 7). The Ares I-X Ground 
Diagnostic Prototype (GDP, reference 9) is a prototype ground diagnostic 
system that provided anomaly detection, fault detection, fault isolation, 
and diagnostics for the Ares I-X first-stage Thrust Vector Control (TVC) 
and for the associated ground Hydraulic Support System (HSS) while the 
vehicle was in the Vehicle Assembly Building (VAB) at Kennedy Space 
Center and while it was on the launch pad. The TVC is used to steer the 
vehicle during ascent by moving the nozzle of the first-stage solid rocket 
booster. The HSS provides hydraulic pressure for testing the TVC before 
launch. GDP is intended to serve as a prototype of a future operational 
ground diagnostic system for Ares I or other future launch vehicles. 

The prototype combines three existing diagnostic tools: TEAMS, SHINE, 
and IMS. TEAMS (Testability Engineering and Maintenance System) is a 
model-based tool that is a commercial product from Qualtech Systems Inc. 

It uses a qualitative model of failure propagation to perform fault isolation 
and diagnostics. GDP integrated TEAMS models of the TVC and of the 
ground hydraulics to provide integrated fault isolation of both systems. 

SHINE (Spacecraft Health Inference Engine, reference 10) is a rule-based 
expert system that was developed at the NASA Jet Propulsion Laboratory. 

SHINE rules were developed both for fault detection and operating mode identification. The prototype 
uses the outputs of SHINE as inputs to TEAMS. Finally, IMS was used for anomaly detection in 
parallel with the TEAMS/SHINE combination. The expectation was that TEAMS and SHINE would 
detect all of the known failure modes that were modeled, while IMS would have the potential to detect 
unknown failure modes and anomalies that are not yet failures. 

Because the Ares I-X TVC and HSS are very similar to the corresponding systems on Shuttle, IMS 
was trained on historical Space Shuttle data and tested on historical Shuttle data into which simulated 
failures were inserted. During the Ares I-X pre-launch period, IMS used this knowledge base to 
process Ares I-X data while the vehicle was in the Vehicle Assembly Building (VAB) and at the 
launch pad. 

This material is declared a work of the U.S. Government and is not subject to copyright protection in 
the United States. Approved for public release; distribution is unlimited. 

Presented at ISA POWID 2010 Symposium, June 7-10, 2010, Summerlin, NV; http://www.isa.org 



Figure 7: Ares I-X launch 
from Kennedy Space Center, 
October 28, 2009. 
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IMS flagged three periods of 
anomalous behavior for the Ares I-X 
data gathered in the VAB and fewer 
at the launch pad. In each case, 
analysis confirmed that the 
anomalies were caused by 
operational differences between 
Shuttle and Ares I-X. For example, 
differences in how actuator tests are 
performed in Ares I-X vs. Shuttle 
caused false alarm 1 , shown in 
Figure 8. In recent years, the TVC 
actuator tests performed in the VAB 
have all been “pinned” tests, 
meaning that the actuator is 
physically pinned to the nozzle 
during testing, so that the nozzle 
moves during the test. The first TVC 
actuator position test performed in 
the VAB for Ares I-X was an 
“unpinned” test, meaning that the 

actuator was detached from the nozzle, and the nozzle did not move during the test. Because the 
actuator was unpinned, it was able to move through a larger range of motion that is not possible during 
pinned testing. IMS therefore saw position values that it had never seen in the Shuttle data, which it 
flagged as anomalies. These anomalies are “false alarms” in the sense that they are not failures. 
However, they do illustrate the ability of IMS to detect new data that is different from what it has seen 
before. Training on operational data from the vehicle being monitored would eliminate this issue of 
flagging nominal operating behavior as anomalous; it would flag only behavior that differs from the 
data on which it was trained. 
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Figure 8: IMS scores for Ares I-X Sept. 17, 2009 VAB operations. 
Periods during which IMS detected anomalies that were not failures 
are labeled as "false alarms" and were caused by differences in 
operation between Shuttle (the training data set) and Ares I-X. 


GROUND SUPPORT EQUIPMENT 

Another prototype for using IMS for anomaly detection was developed for the liquid hydrogen (LH2) 
Ground Support Equipment (GSE) used to fill and drain the vehicle fuel tank, with the expectation that 
next generation launch vehicles will also have liquid-fueled engines. For demonstration purposes, we 
trained IMS on Shuttle data. One such demonstration involved an LH2 leak at the Ground Umbilical 
Carrier Plate (GUCP) - which is the interface of the External Tank (ET) and the hydrogen vent line - 
on Space Shuttle mission STS- 119 in March 2009 and then again on STS- 127 in July 2009. On both 
missions, during the final stages of loading LH2 (“LH2 tanking”) into the ET, sensors measured a 
significant leak near the GUCP, leading to launch scrubs. Figure 9 shows the data for some of the 
relevant parameters for LH2 tanking. 

For the demonstration, we trained IMS on two configurations of the same data set from a single 
nominal tanking (from the final tanking prior to the launch of STS- 1 19). In one configuration, we used 

This material is declared a work of the U.S. Government and is not subject to copyright protection in 
the United States. Approved for public release; distribution is unlimited. 

Presented at ISA POWID 2010 Symposium, June 7-10, 2010, Summerlin, NV; http://www.isa.org 



all seven LH2 system parameters. In the other, we 
used just four parameters, eliminating a discrete 
valve-open indicator and two parameters 
indicating local H2 concentration (the leak 
detectors). The remaining four parameters 
included two pressure parameters and two 
temperature parameters. The test data set was 
from the off-nominal STS-119 tanking. The IMS 
composite deviation scores (i.e., the distance or 
deviation from a test set data vector to the nearest 
nominal cluster) for the seven-parameter 
configuration are shown in Figure 10 and the 
composite deviation scores for the four-parameter 
configuration are shown in Figure 11. Notice the 
similarity of the shape of the seven-parameter IMS 
composite deviation score to the tanking data 
shown in Figure 9. The score is very closely tracking the leak detector measurement. The deviation 
score increase corresponds exactly with the leak detector increase. Note that even after removing the 
leak detectors from the data set, IMS continues to indicate anomalous behavior, though a bit delayed 
and not quite as strong as the indications from the full vector. This highlights IMS’s ability to detect 
off-nominal states even when direct measurements are not available. 


Figure 9: LH2 tanking data. The red plot (middle) 
shows the measurements from a GUCP-local leak 
detection sensor. The green plot (top) shows an ullage 
pressure measurement. The blue plot (bottom) shows 
a discrete vent valve open indicator. Approximately 
six hours of data is shown. 



Figure 10. IMS composite deviation score for STS- 
119 off-nominal data set trained on seven 
parameters. One hour of data is shown. The red line 
represents the alarm threshold. It is user-settable in 
the GUI. 



Figure 11. IMS composite deviation score for STS- 
119 off-nominal data set trained on four parameters. 
One hour of data is shown (same period as in Fig. 
10). As in Figure 10, the red line is the user-settable 
alarm threshold. 


CONCLUSIONS 

Through practical application, it has been demonstrated that data-driven system health monitoring, 
such as performed by the Inductive Monitoring System (IMS), can be useful in a variety of space 
mission operations settings. Furthermore, data-driven methods can complement other data analysis and 
diagnosis tools, together providing integrated system health management and fault recovery 
recommendations. A number of NASA projects incorporating data-driven anomaly detection have 
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been deployed or are under development. The emergent projects will provide proof of concept 
demonstrations by combining data-driven techniques with model-based and rule-based software tools 
for fault management. They will also produce recommendations on which types of systems would 
most benefit from data-driven and integrated data-driven, rule-based, and model-based approaches for 
fault detection and health management. This information will help guide NASA as it builds operations 
and ground support systems for next-generation space programs as well as providing guidelines for 
commercial and other government applications for the technologies. In particular, the lessons learned 
from applications to space operations directly transfer to application of IMS by the power industry. 
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